Stack Exchange

QotW #3: Does an established SSL connection mean a line is really secure?

2011-07-29 by . 0 comments

Post to Twitter

Last week, we looked at the hardening tag. Today we are going back on a specific question : Does an established SSL connection mean a line is really secure?

Why did we pick up this question? Because almost everyone has heard of SSL, but many are not sure how it works and what it is used for.

Well, the first thing we need to talk about is history of the protocol.

Secure Sockets Layer

The Secure Sockets Layer (SSL) is a cryptographic protocol – now renamed to  Transport Layer Security (or TLS). This protocol is designed to create eavesdropping-proof and tampering-proof communication over the Internet and other untrusted networks.

Originally developed by Netscape, the protocol came out in 1995 with its 2.0 version (1.0 was never publicly released). But SSL 2.0 came with some serious security flaws, which included a Man in the Middle vulnerability, which could allow an attacker to sit in the middle of an encrypted communication, unknown to either end, and decrypt the traffic. A new version was released in 1996 as SSL 3.0. The next step of the standard is SSL 3.1 also named TLS 1.0. Only a few improvements were made for this version, but enough to make TLS 1.0 and SSL 3.0 incompatible. The current version of TLS is the 1.2 release from 2008.

Applications

So what is it used for? Well many people use it on a regular basis. In fact, TLS is used on many websites to provide the HTTPS connections. But it can also encapsulate other protocols, like FTP, SMTP, NNTP or XMPP. You can even use it to secure an entire VPN as with OpenVPN.

So is it secure?

The question can’t be answered as is. It depends…

First thing to rule out is that you are not using SSL < 3.0 versions. Since they all showed flaws they should not be used now.

Secondly we must ensure the implementation is correct. This question discusses the SSL TLS Renegotiation Vulnerability which is present in some browser versions.

Next we must make sure the connection is using encryption. What? Yes: TLS supports a mode of NULL encryption.

From curiosity I’ve looked in the about:config page of Firefox 5.x. Be relieved, all ssl2 settings and null encryption mode are disabled.

And finally you need to check that the connection has been established with regard to the protocol. You may be curious on what you could have done not to respect the protocol, let me explain:

Handshaking

The connection is established in multiple steps called a handshake.

  • The client connects, and if it requires a secure connection it sends a list of supported ciphers.
  • The server picks a cipher from the list (Usually the first in the client list which is compatible with the server list, not necesarrily the strongest), then it notifies the client.
  • The server also sends back its identification, packed into a digital certificate. This certification contains the asymmetric public key of the server and it is signed by a Certificate authority.
  • The client MAY contact this Certificate Authority to confirm the validity of the server’s public key. This is very important, but the cost of online verification makes it impractical. So usually, the browser embeds Certificate Authority public key to perform an online check of the server’s certificate.
  • To generate the session keys, the client encrypts a random number using the server’s public key. Asymmetric cryptography makes deciphering the number without the private key infeasible.
  • Now the client and the server have a shared secret they can use to derive the keys for the actual connection.

Protocol failure

One of the key point in this scenario is the verification of the Certificate. Did you ever connect to a site and see your browser pop up a message about the certificate? Did you read the message? Usually those kind of security warning are here to tell you that the server certificate has expired, or that it is not signed by a trusted authority.

Theses warnings are critical! You may be subject to a man in the middle attack. By clicking : go to this site anyway, you are giving your browser the express command to trust the certificate you were presented. But, unless you had verified it from the Certificate Authority yourself and decided it should be trusted, you could have accepted a forged certificate by a compromised authority. Your connection is then no longer secure.

Conclusion

Does this means that respecting the protocol ensures your security? Well yes.

Provided you made all the verifications, and as AviD said in the today’s featured question:

While there are some mostly theoretical attacks on the cryptography of SSL[TLS], from my PoV its still plenty strong enough for almost all purposes, and will be for a long time.

But I should ponder that yes the connection is secure. And even if we will not turn into paranoiacs of security, one should always ask oneself what the server will be doing with the data provided. It is a good thing to send data on a secured connection, but this has no meaning if the other endpoint forwards them on unsecured lines.

To dig more:
« | »

Comments are closed.